假設顧客對客服機器人說：「幹，等了一週還沒收到，幫我查一下配送進度。」

這句有髒話，也有清楚的客服需求。如果系統只回「你的內容不符合規範」，配送問題仍然沒處理。反過來，機器人接受了請求，卻回覆「你自己不會查嗎」，同樣背離了客服應有的服務。

我認為，對客 Chatbot 的 HAP 防護應該從這個差別出發：讓合理的需求繼續得到協助，同時避免機器人產生辱罵、仇恨或其他不當回覆。 使用者的語氣、要求系統做的事，以及系統最後說出口的話，必須分開判斷。

髒話、辱罵與仇恨，不宜用同一個開關處理

HAP 是仇恨言論、辱罵與粗俗用語（Hate speech, Abusive language, Profanity）的合稱。仇恨言論涉及針對身分或群體的貶抑、排斥；辱罵涉及羞辱、攻擊對象；粗俗用語則包括髒話。它們可能一起出現，對服務流程的影響卻不一定相同。

開頭的顧客在抱怨配送延誤。若企業允許受理帶情緒的查詢，偵測到髒話之後，仍然可以處理配送問題。機器人不必認同顧客的用語，也不必重複那個字，直接回到需要協助的事情即可。

如果請求改成「幫我寫一段話羞辱客服人員」，系統被要求做的事就不同了。拒絕生成辱罵內容，再引導對方說明申訴事項，可以同時保留申訴管道與回覆的界線。

再看另一句：「客服剛才罵我『你自己不會查嗎』，我要申訴。」相同的貶抑文字出現在引文裡，但使用者是在回報事件。只因命中這句話就拒絕受理，會連需要被處理的問題也擋掉。判斷需要看誰說了這句話、針對誰，以及現在要求系統做什麼。

這也是偵測結果與服務處置需要分開的原因。把普通用語誤認成辱罵，是偵測誤判；正確找到髒話，卻因此拒絕一個政策允許的配送查詢，則是處置規則出了問題。兩者都可能造成誤擋，但修改模型或降低門檻，未必能解決後者。

客服也不必接受任何形式的互動。涉及威脅或持續騷擾時，企業可以依政策停止自動服務或轉交人工。這些界線應該說清楚，讓「含有不當用語」對應到具體處理，而不是把所有情況都交給一個總分決定。

輸入與輸出，代表不同的服務責任

輸入檢查（Input Toxicity）要回答的是：這個請求能否受理，需要澄清、引導，還是限制後續互動？輸出檢查（Output Toxicity）則要確認：企業是否允許機器人把這段回覆交給使用者？

兩邊使用相同的偵測工具，仍可以採用不同政策。顧客帶著情緒詢問配送，和機器人主動貶抑顧客，不能只因含有相似詞句就受到相同處理。前者可能仍有合理需求，後者是服務本身產生了不當回覆。

Amazon Bedrock 的內容過濾文件就提供了分別設定輸入與輸出過濾強度、處理動作的方式。這類介面的用途，是讓企業能把兩邊的責任寫進設定；具體要採多嚴格的條件，仍取決於服務允許什麼互動。

對客回覆若包含辱罵，可以在交付前攔下，改用事先準備的中性訊息，或重新生成後再檢查。顧客最後看到的內容，才是企業實際提供的服務。只留下「已偵測到不當回覆」的紀錄，卻仍把原文送到畫面上，對使用者沒有保護作用。

替代回覆也需要維持客服的基本責任。如果還沒取得配送結果，就不該說「已查到配送狀態」。如果目前只能轉交人工，就如實交代接下來能做什麼。移除不當用語之後，服務仍須誠實、可理解，而不是只剩一段不帶髒話的拒絕訊息。

門檻反映取捨，不能代替服務政策

HAP 防護很容易被簡化成「分數超過多少就擋」。門檻確實會影響攔截範圍，但它必須放在已經說清楚的處理規則裡。

對分數越高代表風險越高、採用高於門檻就攔截的判斷方式而言，降低門檻會讓更多內容被攔下。其中可能有原本漏掉的辱罵，也可能有正常用語或應該受理的申訴。若一律以「擋得更多」當成改善，就會忽略合理需求遭到拒絕的代價。

反過來，為了讓抱怨能通過而放寬所有條件，也可能讓真正不應交付的回覆被放行。因此，應先判斷錯誤發生在哪裡：是文字被誤認、缺少前後文，還是政策把所有命中都設成拒絕？知道原因，才有辦法選擇修改偵測、補上情境，或調整處理動作。

髒話清單與語意分類器也有不同用途。Bedrock 的字詞過濾依指定字詞或片語做精確比對，適合處理明確禁止出現的用語。若要區分抱怨、轉述與要求生成辱罵，就還需要能利用前後文的判斷。選擇方法之前，要先知道希望它回答哪個問題。

模型給出的分數，也不宜直接當成違反政策的機率。分數代表什麼、和人工判斷是否一致，都需要釐清。服務若面向台灣使用者，就應以正體中文、台灣用語與中英混用的實際語句來看這些判斷，而不是沿用另一個語言或場景裡順手的門檻。

比較不同設定時，我會同時看應該攔下的內容是否被放行，以及允許受理的請求是否遭到拒絕。這兩邊反映不同代價。尤其要保留轉述辱罵的申訴、帶情緒的正常需求，以及沒有髒話卻貶抑顧客的回覆，才看得出防護是在理解服務情境，還是只對某些字詞反應。

回到客服要完成的事

對開頭那位顧客而言，問題仍然是商品尚未送達。只要請求落在企業願意受理的範圍內，機器人就應把互動帶回配送查詢；若對方要求生成辱罵內容，則拒絕那個要求，保留合理申訴的入口。

企業採用 HAP Guardrails，需要決定的是這些互動界線：哪些內容可以進入服務、哪些要求應該拒絕，以及機器人可以用什麼方式回應。偵測器提供判斷依據，服務政策決定處理，最後交付的內容則要符合對客責任。

因此，我會把「合理需求能繼續被處理」和「不當回覆沒有交給顧客」一起看。客服可以容納情緒，也必須有明確界線；HAP 防護的價值，就在於讓這兩件事能在同一個服務裡成立。

參考資料

• Amazon Bedrock：內容過濾與輸入／輸出設定
• Amazon Bedrock：字詞過濾